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In the event thai the server computer (900) 
terminates the session, such as upon unloading 
the instruction (360) from the browser (210). the 
browser (210) causes the server computer (900) 
to de-allocate the resource (340). 
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COMSIUNICATZON BETWEEN CLIENT AND SERVER COHFUTERS VIA 
KTTP, METHOD, COMPUTER PROGRAM PRODUCT AND SYSTEM 

Field of the Invention 

5 

The present invention generally relates to data 
processing and, more particulaurly, relates to computer 
systems, conqputer programs, and methods for commixnication 
between client and server computers by hypertext transfer 
10 protocol (HTTP) and browsers. 

Background of the Invention 

In most data communication systems, it is required to 

15 assure the complete transmission of information between 
two computers . 

Typically, the user operates a personal computer 
(referred to as "client computer") that has to 
communicate with a remote computer (referred to as 

20 "server computer"). The client computer has communication 
software to communicate with the server computer; the 
server computer has application software to execute a 
business appl icat ion • 

During the communication dialog (also referred to as 

25 "session"), the user enters orders fe.g., for commercial 
items), issues a query (e.g., in a database), requests 
the server computer to analyze data, or performs other 
actions. During each session, the server computer 
allocates resources, for example, to store previous input 

30 data and intermediate results.* 

Traditionally, the communication software on the 
client computer is specialized to the particular 
application software of the served computer. Often the 
communication software comprises a graphical user 

CONFIRMATION COPY 
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interface that is tailored to the application. Client and 
server conputers use communication protocols that 
immediately notify the server computer when the user at 
the client computer terminates the session. Before 
5 terminating, the server computer asks the user to save 
data that he or she has inputted (so-called "user 
committing") - The server computer then releases (de- 
allocates) the resources. 

Using specialized commiini cation software at the 

10 client computer is inconvenient. Besides the time that is 
required to install it, installing the communication 
software might require the payment of license fees. Also, 
regular and costly updates are required. There is a 
tendency to communicate with standard "off-the-shelf" 

15 software such as internet browsers. Browsers are 
installed in almost every personal computer. The 
hypertext transfer protocol (HTTP) became the standard 
communication protocol in the internet. However, HTTP 
does not automatically notify the server computer about a 

20 session termination by the client computer. 

Typically, the server computer waits for a 
predetermined period of time after the last client- 
server-communication and then releases the resources- 
Keeping the resources allocated during this period is 

25 inconvenient, for example, because the resource blocks 
memory and slows down performance. 

For client-server communication, the following 
references are useful: US 5,848,246 (Gish) , US 6,011,805 
(Esteve) . 

30 There is an ongoing need to provide improved computer 

systems, computer programs, and methods for communication 
between client and server computers that use HTTP- 
browsers . 
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Summary of the Invention 



The present invention provides improved client-server- 
communication, while the client computer uses a standard 
5 HTTP-browser. Substantially simultaneously with 

establishing a session by allocating a resource at the 
server computer, the server computer sends a termination 
instruction to the browser. The instruction remains in 
the browser unexecuted dxiring the whole session. In the 
10 event that the server computer terminates the session, 
such as upon unloading the instruction, the client 
computer causes the server computer to de-allocate the 
resource. 

15 As expressed in claim 1, the present invention relates to 
a method for communication between a client computer and 
a server computer in that both computers use HTTP. The 
client computer uses an HTTP-browser. The method 
comprises the following steps: 

20 sending a first request from the client computer to 

the server computer; 

upon receiving the first request, the server 
computer, (i) allocating a resource at the server 
computer, the resource with an identifier, and (ii) 

25 returning a predetermined close instruction to the 

browser, the close instruction carrying the identifier; 

upon unloading the close instruction from the browser 
of the client computer, sending a second request from the 
client computer to the server computer, the second 

30 request carrying the identifier and indicating to de- 
allocate the resource; and 

upon receiving the second request from the client 
computer, by the server computer de-allocating the 
resource. 
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It is an advantage that the close instruction in the 
browser virtually couples the client computer to the 
server con^uter. In the event of unloading, the server 
computer is notified and is able to release the resource. 

5 Further, the browser is a standard browser that 

interprets the close instruction but that does not need 
to be modified. 

Preferably, after the server computer has returned 
the predetermined close instruction, and before the 

10 server conputer receives the second request from the 

client computer, the server computer consecutively sends 
content pages to the client computer. Preferably, in the 
step returning the predetermined close instruction, the 
browser presents the close instruction in a first frame 

15 and presents the content pages in a second frame. 
Preferably, the close instruction prevents selected 
content pages from being cached by the browser. 
Preferably, when sending the second request, the client 
computer sends the second request to a predetermined 

20 address of the server computer. Preferably, in the step 
returning a predetermined close instruction, the 
predetermined close instruction comprises a script. 
Preferably, in the step returning a predetermined close 
instruction, the script does not lead to a presentation 

25 by the browser. 

As expressed in claim 8, the present invention relates to 
a computer program product for HTTP-communication between 
a client computer and a server computer, wherein the 
30 client computer has a browser. The computer program 
product has program code portions that cause a client 
processor in the client computer and a server processor 
in the server computer to control the communication. The 
computer program product comprises: code portions that 
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cause the client processor to send a first request to the 
server computer; code portions that - upon receiving the 
first request by the server conqputer - cause the server 
processor, to (i) allocate a resource at the server 

5 computer, the resource with an identifier, and to (ii) 
return a predetermined close instruction to the browser, 
the close instruction carrying the identifier; code 
portions that - upon unloading the close instruction from 
the browser of the client computer - cause the client 

10 processor to send a second request to the server 

computer, the second request carrying' the identifier and 
indicating to de-allocate the resource; and code portions 
that - upon receiving the second request from the client 
computer - cause the server processor to de-allocate the 

15 resource. 

Preferably, the code portions cause the client 
processor to provide such a close instruction that the 
browser provides a first frame to present the close 
instruction in a first frame and provides a second frame 

20 to present content pages that the client computer 

receives from the server computer. Preferably, the code 
portions cause the client processor to provide such a 
close instruction that caching selected content pages by 
the browser is prevented. Preferably, the code portions 

25 cause the client processor to provide, such a close 

instruction that the client computer sends the second 
request to a predetermined address of the server 
computer . 

As expressed in claims 12 and 13, the present 
30 invention also relates to separate computer readable 
media that separately store the program code portions 
causingf the client processor and the server processor to 
operate . 
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As expressed in claim 14, the present invention relates 
to a computer system in that a client computer and a 
server computer use HTTP for communication and in that 
the client computer uses an HTTP-browser, The client 
5 computer sends a first request to the server computer; 
the server computer (upon receiving the first request) 
(i) allocates a resource (resource having identifier), 
and (ii) returas a predetermined close instruction to the 
browser of the client computer (the close instruction 

10 carrying the identifier) ; the client computer (upon 

unloading the close instruction from the browser) sends a 
second request to the server computer (the second request 
carrying the identifier and indicating to de-allocate the 
resource) ; and the server computer (upon receiving the 

15 second request from the client computer) de-allocates the 
resource.. 

Preferably, the client computer presents the close 
instruction in a first frame and presents the content 
pages in a second frame. Preferably, the server computer 
20 provides the close instruction such that in the client 
computer the close instruction prevents selected content 
pages from being cached by the browser. 

As expressed in claim 17, the present invention relates 
25 to a method for communication betwefn a client computer 
and a server computer. Both computers use HTTP; the 
client computer uses an HTTP-browser. The client computer 
sends a request to the server computer. 
Upon receiving the request, the server computer: 
30 allocates a resource at the server computer (the resource 
with an identifier and a time-out period) , returns a 
close instruction to the client computer (the close 
instruction with the time-out period and the identifier) , 
measures the time during that communication between the 
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client and server computers is idle, and de-allocates the 
resource when the measured time reaches the time-out 
period. Upon receiving the close instruction, the client 
computer measures the time during that the commimication 
5 between the client computer and the server computer is 
idle, and displays a warning to the user if the measured 
time reaches a priedetermined fraction of the time-out 
period. 

It is an advantage that that unintentional lapsing 

10 the time-out on the client side is prevented. 

As expressed in claim 18, the present invention 
relates to a computer program product for controlling 
HTTP-communication between a client computer and a server 
computer, wherein the client computer has a browser. The 

15 computer program product has a client program portion to 
control a client processor and a server program portion 
• to control a server processor. The program is 
characterized in that the client program product portion 
causes the client processor to send a request from the 

20 client computer to the server computer; upon receiving 
the request by the server computer, the server program 
portion causes the server processor to allocate a 
resource at the seirver computer (resource with identifier 
and time-out period (T) ) , to return a close instruction 

25 to the client computer (close instruction with time-out 
period (T) and identifier), to measure the time (t) 
during that communication between the client computer and 
the server computer is. idle, and to de-allocate the 
resource when the measured time (t) reaches the time-out 

30 period (T) ; and upon receiving the close instruction by 
the client cort^uter, the client program portion causes 
the Client processor to measure the time (t) during that 
the communication between the client computer and the 
server computer is idle, and to display a warning to the 
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user if the measured time (t) reaches a predetermined 
fraction (T/X) of the time-out period (T) , 

As expressed in claim 19, the present invention is 

5 described as a method for communication between a client 
computer and a server computer, (HTTP, client computer 
with HTTP-browser); the method comprises: sending a first 
request from the client computer to the server computers- 
allocating a resource at the server computer, the 

10 resource with an identifier/ returning a predetermined 
response page to the browser, the response page carirying 
the identifier and carrying browser instructions; as 
instructed by the response page, periodically sending the 
second requests by the browser to the server computer, 

15 the second requests carrying the identifier; and at the 
server computer, periodically checking the arrival of the 
second requests with the identifier from the client 
computer and de-allocating the resource in case a 
predetermined time period (T) has lapsed since the last 

20 arrival . 

Brief Description of the Drawings 

FIG. 1 illustrates a simplified block diagram of a 

25 computer network system Jiaving a plxarality of 

computers ; 

FIG, 2 illustrates a simplified block diagram of the 

system in that a client computer and a server 
computer commimicate with each other; 
30 FIG. 3 illustrates a simplified flow chart diagram 

of a method of the present invention; 

FIG. 4 illustrates a display of the client computer 

for that a browser shows a first frame and a 
second frame; 



BNSOOCIO: <W0 ^0197012(k2J_> 



wo 01/97012 PCT/EPOl/06701 

- 9 - 

FIG. 5 illustrates a simplified state diagram for a 

resource that is allocated in the server 
computer; 

FIG. 6 is a simplified code listing of an 

5 instruction that participates in the method 

of FIG. 3; 

FIG. 7 illustrates a simplified diagram of the 

method of the present invention in a further 

embodiment by way of example; 
10 FIG. 8 illustrates simplified diagrams of content 

pages at a previous time point, at an actual 

time point and at a future time point; 
FIG. 9 illustrates a simplified diagram of the 

computer system in further optional method 
1 5 intpl ement a t i ons ; and 

FIG. 10 illustrates a simplified flow-chart diagram 

of the method of the present invention in a 

still further embodiment. 



20 Detailed Description of the Invention 

For convenience, a list of references is provided prior 
to the claims. Logical addresses (e.g., URL) are 
indicated in quotation marks and conveniently cite the 
25 addressed element by its name and reference number; such 
as "server-computer-901" being an address for server 
computer 901. 

FIG. 1 illustrates a simplified block diagram of computer 
30 network system 999 having a plurality of computers 900, 
901, 902 (or 90.q, with q=O...Q-l, Q any nxamber) . 

Computers 900-902 are coupled via inter-computer 
network 990. Computer 900 comprises processor 910, memory 
920, bus 930, and, optionally, input device 940 and 



BNSDOCJD: <W0. 



.0197012A2J_> 



wo 01/97012 PCT/EPOl/06701 . 

- 10 - 

output device 950 (I/O devices, user interface 960). As 
illustrated, the invention is present by computer program 
product 100 (CPP) , program carrier 970 and program signal 
980, collectively "program". 

5 In respect to computer 900, computer 901/902 is 

sometimes referred to as "remote computer", computer 
901/902 is, for example, a server, a router, a peer 
device or other common network node, and typically 
comprises many or all of the elements described relative 

10 to conputer 900. Hence, elements 100 and 910-980 in 

computer 900 collectively illustrate also corresponding 
elements lOq and 91q-98q (shown for q=0) in computers 
90q. 

Computer 900 is, for exaniple, a conventional personal 

15 computer (PC) , a desktop and hand-held device, a 
multiprocessor computer, a pen computer, a 
microprocessor-based or programmable cons\amer 
electronics, a minicomputer, a mainframe computer, a 
personal mobile computing device, a mobile phone, a 

20 portable or stationary personal computer, a palmtop 
computer or the like. 

Processor 910 is, for example, a central processing 
unit (CPU) , a micro-controller \mit (MCU) , digital signal 
processor (DSP), or the like. 

25 Memory 920 symbolizes elements that temporarily or 

permanently store data and instructions. Although memory 
920 is conveniently illustrated as part of computer 900, 
memory function can also be implemented in network 990, 
in computers 901/902 and in processor 910 itself (e.g./ 

30 cache, register), or elsewhere. Memory 920 can be a read 
only memory (ROM) , a random access memory (RAM) , or a 
memory with other access options. Memory 920 is 
physically implemented by computer-readable media, such 
as, for example: (a) magnetic media, like a hard disk, a 
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floppy disk, or other magnetic disk, a tape, a cassette 
tape; (b) optical media, like optical disk (CD-ROM, 
digital versatile disk - DVD) ; (c) semiconductor media, 
like DRAM, SRAM, EPROM, EEPROM, memory stick, or by any 
5 other media, like paper. 

Optionally, memory 920 is distributed across 
different media. Portions of memory 920 can be removable 
or non- removable. For reading from media and for writing 
in media, computer 900 uses devices well known in the art 

10 such as, for example, disk drives, tape drives. 

Memory 920 stores support modules- such as, for 
example, a basic input output system (BIOS) , an operating 
system (OS), a program library, a compiler, an 
interpreter, and a text- processing tool. Support modules 

15 are commercially available and can be installed on 
computer 900 by those of skill in the art. For 
simplicity, these modules are not illustrated. 

CPP 100 comprises program instructions and - 
optionally - data that cause processor 910 to execute 

20 method steps of the present invention. Method steps are 
explained with iriore detail below. In other words, CPP 100 
defines the operation of computer 900 and its interaction 
in network system 999. For example and without the 
intention to be limiting, CPP 100 can be available as 

25 source code in any programming language, and as object 

code ("binary code") in a compiled form. Persons of skill 
in the art can use CPP 100 in connection with any of the 
above support modules (e.g., compiler, interpreter, 
operating system) . 

30 Although CPP 100 is illustrated as being stored in 

memory 920, CPP 100 can be located elsewhere. CPP 100 can 
also be embodied in carrier 970. 

Carrier 970 is illustrated outside computer 900. For 
communicating CPP 100 to computer 900, carrier 970 is 
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conveniently inserted into input device 940. Carrier 970 
is implemented as any computer readable medium, such as a 
medium largely explained above (cf. memory 920). 
Generally, carrier 970 is an article of manufacture 

5 comprising a computer readable meditim having computer 
readable program code means embodied therein for 
executing the method of the present invention. Further, 
program signal 980 can also embody computer program 100. 
Signal 980 travels on network 990 to conqputer 900. 

10 Having described CPP 100, program carrier 970, and 

program signal 980 in connection with- computer 900 is 
convenient. Optionally, program carrier 971/972 (not 
shown) and program signal 981/982 embody conqputer program 
product (CPP) 101/102 to be executed by processor 911/912 

15 (not shown) in computers 901/902, respectively. 

Input device 940 symbolizes a device that provides 
data and instructions for processing by computer 900. For 
example, device 940 is a keyboard, a pointing device 
(e.g., mouse, trackball, cursor direction keys), 

20 microphone, joystick, game pad, scanner. Although the 
examples are devices with human interaction, device 940 
can also operate without human interaction, such as, a 
wireless receiver (e.g., with satellite dish or 
terrestrial antenna), a sensor (e.g., a thermometer), a 

25 counter (e.g., goods counter in a factory). Input device 
940 can serve to read carrier 970. 

Output device 950 symbolizes a device that presents 
instructions and data that have been processed. For 
example, a monitor or a display, (cathode ray tiibe (CRT) , 

30 flat panel display, liquid crystal display (LCD) , 
speaker, printer, plotter, vibration alert device. 
Similar as above, output device 950 communicates with the 
user, but it can also communicate with further computers. 
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Input device 940 and output device 950 can be 
combined to a single device; any device 940 and 950 can 
be provided optional. 

Bus 930 and network 990 provide logical and physical 
5 connections by conveying instruction and data signals. 
While connections inside computer 900 are conveniently 
referred to as "bus 930", connections between coirqputers 
900-902 are referred to as "network 990". Optionally, 
network 990 comprises gateways being computers that 
10 specialize in data transmission and protocol conversion. 
Devices 940 and 950 are coupled to computer 900 by 
bus 930 (as illustrated) or by network 990 (optional) . 
While the signals inside computer 900 are mostly 
electrical signals, the signals in network are 
15 electrical, magnetic, optical or wireless (radio) 
signals . 

Networking environments (as network 990) are 
commonplace in offices,, enterprise-wide computer 
networks, intranets and the internet (i.e. world wide 

20 web) . The physical distance between a remote computer and 
computer 900 is not important. Network 990 can be a wired 
or a wireless network. To name a few network 
implementations, network 990 is, for example, a local 
area network (LAN) , a wide area network (WAW) , a public 

25 switched telephone network (PSTN) ; a Integrated Services 
Digital Network (ISDN) , an infra-red (IR) link, a radio 
link, like Universal Mobile Telecommunications System 
(UMTS), Global System for Mobile Communication (GSM), 
Code Division Multiple Access (CDMA), or satellite link. 

30 Transmission protocols and data formats are known, 

for example, as transmission control protocol/internet 
protocol (TCP/IP) , hyper text transfer protocol (HTTP) , 
secvire HTTP, wireless applicatipn protocol, unique 
resource locator (URL) , a unique resource identifier 
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(URI), hyper text mcurkup langiiage HTML, extensible markup 
language (XML) , extensible hyper text markup language 
(XHTML) / wireless application markup language (VML) , etc. 
Interfaces coupled between the elements are also well 
5 known in the art. For siirqplicity, interfaces are not 
illustrated. An interface can be, for example, a serial 
port interface, a parallel port interface, a game port, a 
universal serial bus (USB) interface, an internal or 
external modem, a video adapter, or a sound card. 
10 Computer and program are closely related. As used 

hereinafter, phrases, such as "the conputer provides" and 
"the program provides", are convenient abbreviation to 
express actions by a computer that is controlled by a 
program. 

15 

FIG. 2 illustrates a simplified block diagram of system 
999 in that client computer 900 and server computer 901 
communicate with each other via network 9 90 (branch 
990-1). Both computers 900 and 901 use the hypertext 

20 transfer protocol (HTTP) ; client computer 900 further 
uses HTTP-browser 210, Browser 210 is the program to 
locate content pages (e.g., in computer 901) and to 
display the content pages (presentation 211, cf. FIG. 4). 
Preferably, browser 210 presents graphics as well as 

25 text. Preferably, browser 210 is a Netscape Navigator or 
a Microsoft Internet Explorer. 

Usually, server computer 901 executes bxisiness 
application 401. It is an advantage of the present 
invention, that browser 210 is software that is 

30 commercially available as a standard browser. In other 
words, computer 900 does not recjuire special software 
that is dedicated for communication with application 401 
in computer 901. 
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During normal operation, browser 210 requests content 
pages from server computer 901, server computer 901 
responds with content (e.g., HTML pages), browser 210 
then causes display 950 to show content pages to the 
5 user. An exemplary content page 335 is syihbolized by an 
exclamation mark. 

Similar elements such as display, memory, processor, 
etc. for the -other computers are not illustrated for 
simplicity. Optionally, client computer 900 also 

10 communicates with conputers 902 and 903 via branches 
990-2 and 990-3, respectively; computers 902 and 903 
execute applications 402 and 403, respectively. 
Optionally, the content pages are generated by 
application computer 902. Likewise, browser 210 requests 

15 pages from application computer 902, application computer 
902 responds with application pages. 

Preferably, application 403 assists the user to 
identify application 401 and 402 out of a plurality of 
applications that are available in the overall network. 

20 Such assistance applications are commercially available 
from SAP Aktiengesellschaft, Walldorf (Baden), Germany 
ixnder the name "workplace" . For convenience, computer 903 
is therefore referred to as "workplace computer" . 
Further illustrated elements are: resource 340 (used 

25 temporarily), requests 230, 240,' instruction 360 and ID 
350 (transmitted via the network) . The function of these 
elements is explained next: 

FIG. 3 illustrates a simplified flow chart diagram of 
30 method 500 of the present invention. Method 500 is a 

method of communication between client computer 900 and 
server computer 901. Both computers 900, 901. use the 
hypertext transfer protocol (HTTP) ; client computer 900 
uses HTTP-browser 210. 
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Method 500 conqprises the following steps: sending 520 
a first request, allocating 531 a resource, returning 532 
a close instruction, sending 560 a second request, and 
de-allocating 580 the resource. Executing the steps 
5 depends on predefined conditions; for convenience of 
explanation, FIG. 3 illustrates the conditions by query 
symbols and YES/NO questions: upon receiving 530 the 
first request (received ?) , upon unloading 540 the close 
instruction (unloaded ?) , and upon receiving 570 the 

10 second request (received ?) . If the conditions are met, 
the execution of method 500 continues (Y=YES) , otherwise, 
the execution of method 500 is suspended (N=NO) • 

Although referred to as communication between client 
computer 900 and server computer 901, communication can 

15 also occur between client computer 900 and computers 
902/903, 

The steps are now e^qplained in detail: 

In step sending 520, client computer 900 sends first 
request 230 to server conputer 901. Preferably, first 

20 request 230 is a \inified resource locator (URL) by that 
client computer 900 identifies business application 401 
on server computer 901 (e.g., "http: //network-990/server- 
computer-901/application-401") . First request 23Q is also 
referred to as "client session command" and is also 

25 referred to by the acronym "USR_OPEN" . 

Preferably, first request 230 informs server computer 
901 that client computer 900 operates according to method 
500. During sending 520, a session is not yet initiated 
because a session ID is not yet created. 

30 Server computer 901 performs steps 531 and 532 upon 

receiving 530 first request 230. 

In step allocating 531, server computer 901 allocates 
resource 340 (at server computer 901) • Resource 340 has 
identifier 350 (session identification) . Resource 340 is 
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sometimes referred to as "session state". Resource 340 
uses memory 921 (cf. explanation of FIG. 1). Identifier 
350 is sometimes referred to as "global lanique session 
ID". For example, identifier 350 coitprises a text portion 

5 with the name of server computer 901 and a numeric 
portion (<server namexsession ID>) . 

The present invention is described in connection with 
a single resource 340, a single session and a single 
identifier 350, persons of skill in the art are able to 

10 implement two or more sessions in parallel. 

As used herein, the term "allocate a resource" 
comprises that server computer 901 stores previous input 
data and intermediate results. 

In step returning 532, server computer 901 returns 

15 predetermined close instruction 360 to browser 210. 
Preferably, close instruction 350 is implemented as a 
HTML-page that comprises a script (e.g., JavaScript) or a 
program' (e.g., JavaApplet) . An example is explained in 
connection with FIG. 6. Close instruction 360 carries 

20 identifier 350. Carrying identifier 350 can be 

accomplished by means well known in the art. For example, 
identifier 3 50 is carried as part of a URL or by a 
cookie. Reception of identifier 350 by client computer 
900 marks the start of a coinmunication session (FIG. 3: 

25 SESSlOlsr_START) , because from now on_both, client computer 
900 and server computer 901, use identifier 350 that is 
related to resource 340. 

As mentioned, client computer 900 performs step 560 
upon unloading 540 close instruction 360 from browser 

30 210. The phrase "upon unloading" is intended to comprise 
the following: 

(1) The user closes browser 210; persons of skill in the 
art are able to detect this, in the example, 
explained in connection with FIG. 6, section 6, 
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closing the browser is detected by the script event 
"onbefore unload" or "onunload". 
(2) From the page that implements close instruction 360, 
the user navigates away to another page. In other 
5 words, a new page displaces the old page (cf . FIG. 4, 

for exaittple, by writing a new address into field 
214). 

It is also possible - although not required for the 
present invention - that the user terminates the session 

10 explicitly, for example, by operating a f-unctional button 
such as an "abort session" button (cf-. 217, 218 219 in 
FIG. 4 or similar ones) , 

In step sending 560, client computer 900 sends second 
request 240 to server computer 901. Second request 240 

15 carries identifier 350. Optionally, second request 240 is 
initiated by direct user interaction, for example, by 
activating a dedicated button. Second request 240 
requires valid identifier 350. Sending 560 second request 
240 is the defined way of notifying server computer 901 

20 that client computer 900 terminates the session. 

Server computer 901 performs step 580 upon receiving 
57 0 second request 240. Second request 240 is xinderstood 
by server computer 901 so that in step de-allocating 580, 
server computer 901 de-allocates resource 340. De- 

25 allocating is the opposite of allocating; server computer 
901 discards previous input data (e.g., from the user) 
and intermediate results (e.g., of application 401). 

Optionally, de-allocating comprises that server 
computer 901 transfers input data and intermediate 

30 results to other memory areas that are reserved for 

application 401. This is often the case when application 
401 responds to a user request to place an order for a 
commercial item and the user finishes a business 
transaction. 
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When resource 340 has been de-allocated from server 
coirgjuter 901, the session has come to its end (FIG. 3: 
SESSION_END) . Server conputer 901 does not need to send a 
response to second request 240 to client computer 900, 
5 Optionally, server conputer 901 responds by a minimum 
response (e.g., « <HTML></HTML> " ) 

FIG. 4 illustrates display 950 of client computer 900 for 
that HTTP-browser 210 (cf . FIG. 2) generates browser 

10 presentation 211. Browser presentations are well known in 
the art; in the example of FIG. 4, presentation 211 has 
back button 213, address field 214, and close button 219, 
warning 205 and a display area for showing frames. 

According to a preferred embodiment, presentation 211 

15 shows first frame 215 and second frame 216, each having 
close buttons 217 and 218, respectively. Since, 
preferably, frame 215 is presented prior to frame 216, 
the frames are also referred to as parent frame 215 and 
child frame 216. Browser 210 implements close instruction 

20 360 into first frame 215. Displaying frame 215 is 
optional . 

Address field 214 shows the HTTP-address (URL) of 
content 335: "http: //network-990/server-coinputer'- 
9'01/application-401/content-335'' . Browser 210 has 
25 requested content page 335 by forwarding the mentioned 
URL to server computer 901. Browser 210 shows content 
page 335 (exclamation mark symbol) received from server 
computer 901 (e.g., from application 401) in second frame 
216. Frame 216 is conveniently an integrated frame 

30 IFRAME . 

Splitting the display screen into frames 215, 216 is 
convenient for the user: Frame 215 informs that session 
management (cf. method 500) is active, for example, by 
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informing that the user can now access application 401 
(e.g., '* APPLICATION READY " ) . 

FIG. 4 also conveniently illustrates exit buttons 
217, 218, 219 by X-symbols. If the user operates either 
5 one, browser 210 detects this as xonloading 540 (cf . 

FIG. 3) . This is an advantage of the present invention. 
The user is free to' close a frame (button 217, 218) or 
even to close browser 210 (button 219) at any time, and 
the further steps 560-580 terminate the session. 
10 Warning 205 is optional and informs the user that 

browser 210 is sending out second request 240. In the 
example of FIG* 4, warning 205 appears after the user has 
caused the unloading event (cf. FIG. 3, 540), and warning 
205 asks. the user for confirmation. 

15 

FIG. 5 illustrates a simplified state diagram for 
resource 340 that is allocated or de-allocated in server 
computer 901. As mentioned, performing method 500 leads 
to allocate or to de-allocate resource 340. As indicated 

20 by plain arrows, first request 230 leads to the state 1 
•allocated" (also: "state-full") and second request 240 
leads to the state 0 "de-allocated" ("state-less"). 

Optionally, indicated by dashed arrows, de-allocation 
can be triggered by a request ("SRVL_CLOSE") from 

25 application 401. In this case, server computer 901 

notifies browser 210 in client computer 900 to remove 
("session closed information") instruction 360 from 
browser 210 or to re-direct browser 210. 

30 Performing session management by method 500 can be (a) 
central session management, or (b) distributed session 
management . 
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In case {a) r close instruction 360 is part of a session 
manager that resides on client computer 900 and that is, 
preferably, responsible for multiple sessions. In other 
words, such a session manager performs the method steps 
5 in parallel for multiple applications (such as 401 or 
402) for multiple resources (such as 340) by receiving 
multiple instructions (such as 360) in parallel. 
Optionally, code to perform the method steps is forwarded 
to client computer 900 from wor3qplace computer 903. In 

10 other words, server computer 901 (or application computer 
902) cooperates with workplace computer 903 to provide 
multiple identification for these multiple resources , 
When frames are used, preferably, a single parent 
frame (e.g., frame 215, FIG, 4) has multiple child frames 

15 (e.g., frame 216) for each resource (also referred to as 
"workspaces" or "channels"). The present invention allows 
to scale session management to multiple computers, 
applications and resources. 

20 In case (b) , client computer 900 receives instruction 360 
from server computer 901. The following example in 
connection with FIG. 6 uses a close instruction that is 
created for each session. 

25 FIG. 6 is a simplified code listing of instruction 360. 
Browser 210 conveniently loads instruction 360 into a 
parent frame. Displaying the parent frame conveniently 
informs the user that session management is active. But 
displaying the frame is not important. 

30 For convenience of explanation herein, multiple 

instructions are sometimes placed on single lines whereas 
programmers would have placed them on separate lines. 
This is especially true for well-known syntax. 
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Code section 1 defines HTML as language, a head 
portion (sections 1-4), a title that is conveniently 
chosen as "instruction-360" , as well as defines the 
script language JavaScript. 
5 Code section 2 defines a global string to store 

second request 240 (referred to as "termination URL") for 
the session in child frame 216. In the exaitiple, request 
240 does not have any other content; is it sufficient to 
target second request 240 by identifier 350 to an address 

10 in server computer 901 that is reserved for de-allocating 
resource 340 (for example, http: //network-990 -server- 
computer-901 . application-401 .resource-340 " ) 

Code section 3 defines a function 
"sending_560_second_request 0 " that implements step 560 • 

15 For convenience of explanation, the fxmction further * 

displays a message with the complete text "Client ...V The 
message reads as: "Client coiiputer 900 is now sending 560 
second request 240 to server computer 901. Second request 
240 is the following URL ..." 

20 Code section 4 defines a fimction to store received 

session identifier 350 (here: identifier contains only 
the termination URL) . 

Code section 5 closes the above script and head 
sections . 

25 Code section 6 defines "upon unloading 540" by the 

event "onunload" and defines that step 560 is then 
executed. 

Code section 7 is not required for the present 
invention. For convenience of explamation, section 7 
30 provides a display that reports method st^s that took 
place in the past: 

"This is first frame 215. Client computer 900 with 
browser 210 had been sending 520 first request 230 (e.g., 
by URL "http: //network-990/server-computer- 
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901/application'-401" ) to server computer 901. Upon 
receiving 530 first request 230, server conputer 901 had 
been allocating 531 resource 340 with identifier 350 and 
had been returning 532 predetermined close instruction 

5 360 in the form of the present HTML-document 

"instruction- 3 60 -htm" with identifier "340". Close 
instruction 360 carries identifier 350 ("340"). HTML- 
document "instruction-360.htm" comprises a termination 
command in the program section 6 with "onxinload". The 

10 session has now started. 

Code Section 8 is optionally and informs the user 
that content pages 335 are indicated inside a content 
frame. 

Code section 9 is also optional and identifies 
15 content page 335 as an IFRAME to display a HTML-file at a 
given address. IFRAMES are well known in the art. 

Code section 10 provides conventional HTML-syntax. 

The following explains advanced session management 
20 features (c) "timer" and (d) "cache prevention" that are 
optionally implemented according to the present 
invention. 

The advanced session management feature (c) "time" is 
explained: 

25 

FIG. 7 illustrates a simplified diagram of a method of 
the present invention in a further embodiment by way of 
example. Method 600 for communication between client 
computer 900 and server computer 901 (symbolized by 
30 vertical lines) via HTTP (computer 900 with HTTP-browser 
210) comprises the following steps: 

sending 601 first request 230 from client computer 
900 to server computer 901 (symbolized by an arrow to the 
right); upon receiving 611 (point symbol) first request 
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230, server "computer 901 (right line) executes the steps 
allocating 612 resource (cf. step 531 in FIG, 3), 
returning 613 close instruction (cf. step 532), measuring 
614 time and de-allocating 614 resource (cf. step 580); 
5 and upon receiving 602 close instruction, client computer 
900 (left line) executes the steps measuring 603 time, 
and displaying 604 warning. 

Details for the steps at server computer 901 are as 
follows : 

10 In step allocating 612, server conqputer 901 allocates 

resource 340 (cf. FIG. 2), resource 340 has identifier 
350 (e.g., URL to resource 340) and has a time-out period 
T. In the example, the period T is 60 seconds 
corresponding to a full pointer turn in a simplified 

15 clock symbol. In step returning 613, server computer 901 
returns close instruction 360 to client coinputer 900 
(similar as described by the other figures) . Close 
instruction 360 also transfers a representation of time- 
out period T (e.g., a number "60" at a predetermined 

20 location in HTML) and transfers identifier 350. In step 
measuring 614, server computer 901 measures the time t 
during that communication between client computer 900 and 
server computer 901 is idle. In FIG. 7, t is 15 seconds. 
The term "idle" as used herein is intended to describe 

25 the absence of content page requests from client computer 
900 that access resource 340 in the present session (as 
defined in connection with FIG 3 ) ; communication that 
relates to other applications is not considered here. In 
step de-allocating 615, server computer 901 de-allocates 

30 resource 340 when the measured time t reaches time-out 
period T, for example after 60 seconds (from receiving 
611) , 

Details for the steps at client computer 900 are as 
follows: In step measuring 603, client computer 901 
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measures the time t during that the communication between 
client computer 900 and server computer 901 is idle. In 
step displaying 604, client computer 901 issues a warning 
(orally or visually, e.g., similar to 205 in FIG. 4) to * 
5 the user if measured time t reaches a predetermined 
fraction T/X of the time-out period T, In the example 
(X = 4/3), the fraction is reached after 45 seconds. 
Since identification 360 of resource 340 has been 
transmitted to client computer 900, the user can now 
10 respond by communicating with server computer 901 to 
refresh (set t=0) . 

The advanced session management feature (d) "cache 
prevention" is explained: 

15 

FIG. 8 illustrates simplified diagrams of content pages 
.335 at a previous time point (t-1), at an actual time 
point (t) and at a future time point (t+1) . Browser 210 
usually has back button 213 (often named "BACK", cf. 
20 FIG. 4), and browser 210 allocates a cache (not 

illustrated) in memory 920 to temporarily store content 
pages 335. 

When the user presses back button 213, browser 210 
changes the display from actual content page 335 at 

25 actual time point (t) to previous content page 335 at 
previous time .point (t-1) . 

As long as application 401 in server computer 901 is 
a read-only type application and content pages 335 
siibstantially remain unchanged, displaying cached pages 

30 is convenient. In some instances, especially for business 
applications, intermediate results stored in reso\irce 340 
at server computer 901 diverge from temporarily cached 
content pages 335 { t-1) on client computer 900- This is no 
longer convenient and might cause serious problems: 
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For example, application 401 is a shopping 
application. The user has located some items ABC into an 
shopping basket icon on content page 335 (t). Resource 340 
(of. FIG. 2) stores ABC; previous content page 335 (t-l) 
5 in the cache comprises ABC as well. The user now 

completes the shopping transaction and therefore requests 
a further content page with payment procedures (not 
illustrated) . Now the user, most likely being influenced 
by the total payable amount for ABC, removes item C from 

10 the basket icon: application 401 returns content page 

335 (t+l) that shows AB; resource 340 ^{cf. FIG. 2) stores 
AB as well. The user now unintentionally presses back 
button 213 but sees cached page 335 (t-l) with ABC- Now 
the display ABC on client conqputer 900 and intermediate 

15 results AB in server computer 901 are different. 

According to the present invention, optionally, close 
instruction 350 prevents content pages 335 from being 
cached by browser 210. This is illustrated by dashed 
lines crossing out content page 335 (t-l). Even if the 

20 user presses back button 213, content pages are reloaded 
from server computer 900 (here: AB) . It is convenient not 
to apply this' rule to all content pages 335. Preferably, 
server computer 901 distinguishes cache-prevented content 
pages 335 from cache-allowed content pages 335. by 

25 attaching tags or by other means. 

The following describes an optional implementation (e) of 
distributed session management: 

30 FIG. 9 illustrates a simplified diagram of contputer 

system 999 for further optional method implementations. 
Illustrated are comiputers 900, 901 and 903. Applications 
are distinguished into main (M) and starter (S) 
applications, addressed by equal domain names. By 
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providing close instructions, the starter applications 
(S) provide session management functionality according to 
the present invention (methods 500 and 500) . The example 
of FIG. 9 is simplified to application 401; persons of 
5 skill in the art can use the same scheme for multiple 
applications (with different domains) in parallel and 
independent from each other. 

(1) The user (of client computer 900) sends a URL to 
the assistance application 403 (the "worlcplace" ) on 

10 workplace computer 903 ( "http: //network-990..■.computer-903- 
/application-403 " ) . 

(2) Application 403 forwards content pages to browser 
210 on client computer 900; the pages offer a number of 
applications, such as main application 401-M.* A hyperlink 

15 goes to the corresponding starter application 401-S- 

(http; //network-'990...application-401-'S" ) • Application 
401-S is a starter for application 401-M (in computer 
900) . The domain *'server-computer-901" is identical for 
starter application 401-S and main application 401-M. 
20 (3) The user selects the hyperlink to 

application 401-S; client computer 900 sends request 230 
to searver computer 901. 

(4) Starter application 401-S allocates resource 340 
(cf, step 531) and returns (cf. step 532) instruction 360 

25 to client computer 900; instruction 360 has session 

management code (e.g., as in FIG. 6, code sections 3, 6). 

(5) Instruction 360 has code that instructs browser 
210 to open IFRAME (e.g., similar as in FIG. 6, code 
section 9) . IFRAME is associated with a link to main 

30 application 401-M (not to the starter, but to the 

application itself) . The user now interacts with main 
application 401-M. 

(6) Upon unloading (cf. condition 540), browser 210 
sends second request 240 to starter application 401-S 
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that de-allocates resource 340 and interacts with 
application 401-M, 



The following describes a still further optional 
5 embodiment (f ) : 

FIG. 10 illustrates a siii5)lified flow-chart diagram of 
the method of the present invention in a still further 
embodiment. Method 700 for communication between client 

10 computer 900 and server coit^uter 901 (HTTP, client with 
browser 210) comprises the following steps: sending 720 
first request 230 from client computer 900 to the server 
computer 901 (cf. FIG. 2); allocating 731 resoxirce 340 at 
the server computer 901 (cf. FIG. 2), resotirce 340 with 

15 identifier 350 (Cf. FIG. 2); returning 732 a 

predetermined response page (similar as instruction 360) 
to browser 210, the response page carrying identifier 350 
and carrying browser instructions; as instructed by the 
response page, periodically sending 760 second requests 

20 240 (cf . FIG. 3) by browser 210 to server computer 901 

(second requests 240 carrying the identifier 350) ; and at 
server computer 901, periodically checking 770 the 
arrival of second requests 240 with the identifier 350 
("ARRIVED IN TIME ?") from client computer 900 and de- 

25 allocating 780 resource 340 in case^a predetermined time 
period (T) has lapsed since the last arrival ("ARRIVED IN 

TIME ? NO" ) . 

If the responses arrive in time ("YES"), resource 340 
remains allocated. This preferred embodiment allows to 
30 de-allocate a resource even if client computer is not 
longer in operation (e.g., after a crash). Optionally, 
step de-allocating 780 is performed after confirmation by 
the user. 
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The present invention can also be considered as computer 
program product (CPP) 100/101 for HTTP- communication 
between client computer 900 and server computer 901. 
Program product (100/101) has program code portions 100 

5 that cause client processor 910 (cf . FIG, 1) in client 
contputer 900 and program code portions 101 in server 
processor 911 in server computer 901 (cf • explanation of 
FIG. 1) to control the communication as described in 
method 500/600/700. The foregoing description is also 

10 applicable for computer system 999 in that client 
computer 900 and server computer 901 communicate as 
described. 
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1. A method (500) for communication between a client 
computer (900) and a server computer (901), both 
computers (900, 901) using the hypertext transfer 
protocol (HTTP), the client computer (900) using an 
HTTP-browser (210); 

the method (500) comprising the following steps: 

sending (520) a first request (230) from the client 
computer (900) to the server computer (901); 

upon receiving (530) the first request (230), 

the server computer (901) , (i) allocating (531) a 
resource (340) at the server computer (901), the 
resource (340) with an identifier (350), and (ii) 
returning (532) a predetermined close instruction 
(360) to the browser (210), the close instruction 
(360) carrying the identifier (350); 

upon unloading (540) the close instruction (360) from 
the browser (210) of the client computer (900), 
sending (560) a second request (240) from the 
client computer (900) to the server computer 
(901), the second request (240) carrying the 
identifier (350) and indicating to de-allocate 
the resource (340) ; and 

upon receiving (570) the second -request (240) from 

the client computer (900) , by the server computer 
(901) de-allocating (580) the resource (340) . 
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2. The metTiod (500) of claim 1, wherein* after the server 
computer (901) has returned (532) the predetermined 
close instruction (360), and before the server 
computer (901) receives (570) the second request 
(240) from the client conputer (900), the server 
computer (901) consecutively sends content pages 
(335) to the client computer (900) . 

3. The method (500) of claim 2, wherein in the step 
returning (532) a predetermined close instruction 
(360), the browser (210) presents. the close 
instruction (360) in a first frame (215) and presents 
the content pages (335) in a second frame (216) . 



15 4. The method (500) of claim 2, wherein the close 

instruction (360) prevents selected content pages 
(335) from being cached by the browser ('210) . 

5. The method (500) of claim 1, wherein in the step 
20 sending (560) a second request (240), the client 

computer (900) sends the second recjuest (240) to a 
predetermined address of the server computer (901) . 

6. The method (500) of claim 1, wherein in the step 
25 returning (532) a predetermined close instruction, 

the predetermined close instruction (360) comprises 
script (1-5) • 

7. The method (500) of claim 1, wherein in the step 
30 returning (532) a predetermined close instruction, 

the script does not lead to a presentation by the 
browser (210) . 
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8. A computer program product (100/101) for HTTP- 
communication between a client computer (900) and a 
server computer (901), wherein the client computer 
(900) has a browser (210), the . computer program 
5 product (100/101) liaving program code portions that 

cause a client processor (910) in the client coinputer 
(900) and a server processor (911) in the server 
computer (901) to control the communication, 
the conqputer program product (100/101) comprising: 
10 code portions that cause the client processor (910) 

to send (520) a first request- (230) to the server 
computer (901); 
code portions that - upon receiving (530) the first 
request (230) by the server computer (901) - 
15 cause the server processor (911) to (i) allocate 

(531) a resoxirce (340) at the server computer 
(901), the resource (340) with an identifier 
(350), and to (ii) return (532) a predetermined 
close instruction (360) to the browser (210), the 
20 close instruction (360) carrying the identifier 

(350); 

code portions that - upon unloading (540) the close 
instruction (360) from the browser (210) of the 
client computer (900) - cause the client 

25 processor (910) to send (560) a second request 

(240) to the server computer (901), the second 
request (240) carrying the identifier (350) and 
indicating to de-allocate the resource (340); and 
code portions that - upon receiving (57 0)' the second 

30 request (240) from the client computer (900) - 

cause the server processor (911) to de-allocate 
(580) the resource (340) . 
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9, The computer program product (100/101) of claim 8, 
wherein the code portions cause the client processor 
(900) to provide such a close instruction (360) that 
the browser (210) provides a first frame (215) to 
5 present the close instruction (360) in a first frame 

and provides a second frame (216) to present content 
pages (335) that the client computer (900) receives 
from the server coirqputer (900) . 

10 10. The computer program product (100/101) of claim 8, 

wherein the code portions cause the client processor 
(900) to provide such a close instruction (360) that 
caching selected content pages (335) by the browser 
(210) is prevented. 

15 i 

11. The computer program product (100/101) of claim 8, 
wherein the code portions cause the client processor 
(900) to provide such a close instruction (360) that 
the client computer (900) sends, the second request 

20 (240) to a predetermined address of the server 

computer (901) . 

12. A computer readable medium (970) storing the program 
code portions of the computer program product (100) 

25 of claim 8 that cause the client- processor (910) to 

operate . 

13. A computer readable medixam (971) storing the program 
code portions of the computer program product (101) 

30 of claim 8 that cause the server processor (911) to 

operate. 
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14. A coni)uter system (999) in that a client computer 
(900) aiid a server computer (901) use HTTP for 
communication and in that the client computer (900) 
uses an HTTP--browser (210); the computer system (999) 
5 characterized in that: 

the client computer (900) sends (520) a first request 
(230) to the server computer (901); 
the server computer (901), upon receiving (530) the 
first request (230), (i) allocates (531) a 
10 resource (340), the resource (340) having an 

identifier (350), and (ii) returns (532) a 
predetermined close instruction (360) to the 
browser (210) of the client computer (900), the 
close instruction (360) carrying the identifier 
15 (350); 

the client coiiqputer (900), upon unloading (540) the 
close instruction (360) from the browser (210) , 
sends (560) a second request (240) to the server 
computer (901), the second request (240) carrying 
20 the identifier (350) and indicating to de- 

allocate the resource (340); and 
the server computer (901), upon receiving (570) the. 
second request (240) from the client coitrputer 
(900), de-allocates (580) the resource (340). 



25 



15. The computer system (999) of claim 14, wherein the 
client computer (900) presents the close instruction 
(360) in a first frame (215) and presents the content 
pages (335) in a second frame (216). 



30 
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16. The computer system (999) of claim 14, wherein the 
server computer (901) provides the close instruction 
(360) such that in the client computer (900) the 
close instruction (360) prevents selected content 
5 pages (335) from being cached by the browser (210) . 
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17. A method (600) for communication between a client 
computer (900) and a server computer (901) , both 
computers (900, 901) using the hypertext transfer 
protocol (HTTP) , the client coniputer (900) using an 

5 HTTP-browser (210) ; 

the method (600) comprising the following steps: 
sending (601) a request (230) from the client 

computer (900) to the server computer (901); 
upon receiving (611) the recpaest (230), 

10 the server computer (901) : 

• allocating (612) a resource at the server 
computer (901) , the resource with an identifier 
(350) and a time-out period (T) , 

• returning (613) a close instruction (360) to the 
15 client computer (900), the close instruction 

(3 60) with the time-out period (T) and the 
identifier (350), 

• measuring (614) the time (t) during that 
communication between the client computer (900) 

20 and the server computer (901) is idle, and 

• de-allocating (615) the resource (340) when the 
measured time (t) reaches the time-out period 

(T) ; and 

upon receiving (602) the close instruction (360), 
25 the client computer (900) 

• measuring (603) the time (t) during that the 
communication between the client computer (900) 
and the sexier computer (901) is idle, 

• displaying (604). a warning to the user if the 
30 measured time (t) reaches a predetermined 

fraction (T/X) of the time-out period (T) , 
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18. A computer program product (100/101) for controlling 
HTTP-communication between a client computer (900) 
and a server computer (901), wherein the client 
computer (900) has a browser (210) , the computer 
5 program product (100/101) with a client program 

portion (100) to control a client processor (910) and 
a server program portion (101) to control a server 
processor (911), characterized in that 
the client program product portion (100) causes the 
10 client processor (910) to send (601) a request 

(230) from the client computer (900) to the 
server computer (901); 
upon receiving (611) the request (230) by the server 
computer (901), the server program portion (101) 
15 causes the server processor (911) to allocate 

(612) a resource at the server computer (901), 
the resource with an identifier (350) and a time- 
out period (T) , to return (613) a close 
instruction (360) to the client computer (900), 
20 the close instruction (360) with the time-out 

period (T) and the identifier (350), to measure 
(614) the time (t) during that communication 
between the client computer (900) and the server 
computer (901) is idle, and to de-allocate . (615) 
25 the resource (340) when the measured time (t) 

reaches the time-out period (T) ; and 
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upon receiving (602) the close instruction (360) by 
the client computer (900) , the client program 
portion (100) causes the client processor (910) 
to measure (603) the time (t) during that the 
communication between the client computer (900) 
and the server computer (901) is idle, and to 
display (604) a warning to the user if the 
measured time (t) reaches a predetermined 
fraction (T/X) of the time-out period (T) . 
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19. A method (700) for coinmunication between a client 
computer (900) and a server computer (901) , both 
computers (900, 901) using the hypertext transfer 
protocol (HTTP) , the client computer (900) using an 
5 HTTP-browser (210); 

the method (700) comprising the following steps: 
sending (720) a first request (230) from the client 

computer (900) to the server computer (901); 
allocating (731) a resource (340) at the server 
10 computer (901), the resource (340) with an 

identifier (350); 
returning (732) a predetermined response page to the 
browser (210), the response page carrying the 
identifier (350) and carrying browser 
15 instructions; 

as instructed by the response page, periodically 
sending (760) the second requests (240) by the 
browser (210) to the server computer (901) , the 
second requests (240) carrying the identifier 
20 (350); and 

at the server computer (901), periodically checking 
(770) the arrival of the second requests (240) 
with the identifier (350) from the client 
computer (900) and de-allocating (780) the 
25 resource (340) in case a predetermined time 

period (T) has lapsed since the last arrival. 
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1 <HTML> <HEAD> <TITLE> lnstruction-360 </TITLE> 

<script language="JavaScript"> 

2 var gs TerininationURL=" ..." 

3 function sending_560_second_request() 

if (gsTerminationURL != "") 
alert("sending_560_second_request_240: n" 
+ "Client ...:" + gsTERMINATIONURL ); 

4 function receiveSesslnfoi termURL ) 

gsTerminationUilL = termURL : 

5 </sripl></Head> 

6 <BODY onunload="sending_560_second_request0"> 

7 Tills is first frame 215 .. . Tlie session has now started. 

8 Preferably, content frames are indicated inside a content 
frame: 

9 <IFRAME scr="content-page-335.litm" widtli="50%" 
heiglit="50%" frameborder="yes" scroUing="yes" > 

10 </IFRAME> </BODY> </HTML> 
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